Taeluf.com

Status

Jan 30, 2024

  • TODO Terms & Conditions: Currently, Terms are agreed to when someone registers for an account. There is a mechanism to make sure that somebody agreed, and if they did not, then the registration fails. However, there is no mechanism logging the date of agreement. There is also no mechanism to check for agreement later, in case of changes to the terms. There is also no mechanism for notifying of new T & Cs, and there is no mechanism to agree to new T&Cs. Pages should be disabled if the current terms are not agreed to, and logging in should require an agreement to any new terms & conditions. The date that T&Cs are updated is also not logged anywhere.
  • TODO Disabled Pages: when pages are disabled, I'm pretty sure they're just blank. Also, there's not a clear way to REPLACE a page (just add a route to liaison?). Disabled pages need to have some kind of message and navigation. This should be standardized, I think, just to make it easy for me.

Jan 29, 2024

  • TODO: Navigation
    • DONE Links on user pages are poor
    • DONE T&C page has no navigation. Should direct back to login, or to dashboard (depending on current login state).
    • TODO When User forms submit, they should redirect back to the dashboard (or other appropriate page) or provide navigation for this purpose.
      • show_error() in Validation class now will provide a 'return to' link, if the link name exists in the Links view. I made sure this works for submitting a reset-password request. But I might need to add links for others. I might want to add additional navigation too. I think the success submission does not have this feature, idk. Need to continue review on this.
    • TODO add links to 'dashboard' on pages that inform the user they are already logged in. Ex: 'register' page will tell you to logout before registering a new account. This should also direct you to the dashboard page.
  • TODO: Document how to create a page theme
  • TODO: Review Documentation on how to deliver user lib content without a page theme
  • TODO: Tests
    • TODO Get all tests working (old/ServerOrig/ contains deliver-test-hacks.php which I probably need to use in the current server so that I can run my tests correctly. I'm not real clear on this.)
    • TODO Write new tests as-needed
  • TODO: Dashboard/Admin GUI
    • TODO Configuration to disable the Liaison dashboard view
    • TODO Configuration to disable user pages (like register)
    • TODO Configuration to change base_url for user lib.

Jan 28, 2024

  • DONE: Finish fixing all my tests. There are only three remaining.
  • TODO: Go over Jan 27 and Jan 23 notes, and copy all TODOs up.

I updated documentation for styling, mainly just pointing to liaison. most of my work was done in code scrawl and liaison.

(later) I updated Validation to stop relying on args for everthing and instead have strongly typed paramaters. Modified some of the form pages to accommodate.

I added the deliver-test-hacks, and made some other modifications to get most of my tests passing.

test Login::AlreadyLoggedIn() is failing because the response does not contain <html>. In the login.php public file, the validation sequence has it fail and show an error message if the user is already logged in, but then it follows my calling show_form(). As-is, when the is_logged_in() call fails, a User\BlackHole object is returned, so when show_form is called, nothing happens.

Actually ... I'm not sure that's the issue. It is still a successful request to a public file, so why is the page layout not being applied?

OH OH OH. The server logs say PHP Fatal error: Uncaught Lia\Exception: View 'null:user/Links' has not been added to Liaison. in /home/reed/data/projects/php/Liaison/code/addon/View.php:121.

Well, fixing the links on user pages was next on my TODO anyway. So that's why the full page isn't displaying ...

Done for today. tired. hoping that coding satisfies my craving so I can relax and enjoy my pre-bed tv time.

Jan 27, 2024

  • TODO: Document how to create a page theme
  • TODO: Review Documentation on how to deliver user lib content without a page theme

Styling: Document how to overwrite built-in styling

  • DONE Honestly, this is Liaison documentation. I should just write the docs over there and direct people to that.
    • I just direct toward Lia documentation, EXCEPT i provide a sample function for removing css files via sorter.
  • DONE Remove the built-in CSS files
  • DONE Add your own CSS files
  • DONE Supplement built-in css files with your own
  • DONE Add CSS code without modifying styles

Jan 23, 2024

  • DONE: Mobile-friendly dashboard page
    • NOTE Adding the tag <meta name="viewport" content="width=device-width, initial-scale=1" /> to the header ... doesn't help, because it still uses the standard three-column view. Let's flex it.
    • DONE added css with <600px media query
  • DONE: Styling
    • DONE Document how to overwrite the built-in styling.
    • DONE the querySelectors in the css file(s) should be more targeted.
      • DONE dashboard.css
      • DONE login.css
      • DONE register.css
      • DONE request.password_reset_form.css
  • TODO: Navigation
    • TODO Links on user pages are poor
    • TODO T&C page has no navigation)
    • TODO When User forms submit, they should redirect back to the dashboard (or other appropriate page) or provide navigation for this purpose.
  • TODO: Tests
    • TODO Get all tests working (old/ServerOrig/ contains deliver-test-hacks.php which I probably need to use in the current server so that I can run my tests correctly. I'm not real clear on this.)
    • TODO Write new tests as-needed
  • TODO: Dashboard/Admin GUI
    • TODO Configuration to disable the Liaison dashboard view
    • TODO Configuration to disable user pages (like register)
    • TODO Configuration to change base_url for user lib.

Jan 21, 2024

  • DONE Started 'Testing' documentation in the README, but some questions/docs are unanswered (visit /user/ for manual testing. Login with (????). Test email sending how(???))
  • DONE: /user/initialize/ fails to load because Package::__construct() calls get_user(), and the database tables do not exist when this happens. The init page needs to work when the DB is not initialized. ... SOLUTION: I no longer get_user() during Package::__construct(). It was unnecessary overhead that was forced onto every request, even for pages that didn't need to load up a user.
  • DONE: None of my user pages should work while risky_web_initialization is enabled, EVEN if the initialization pin file exists. The ONLY page that should work is the /user/initialize/ page. (ALL pages are disabled, actually, when risky web initialization is enabled. Non-user pages cannot be accessed either.)
  • DONE: The init server has a user-configs.json file that has debug_to_textfile as the configuration for the mail service. The dropdown on the 'configure user login' dashboard panel does not match this setting. Additionally, this setting should be reset to debug each time the init server is started.
  • DONE: The dashboard page does not indicate which panel is selected in the nav menu on the left.
  • DONE: The dashboard page is not mobile or portrait friendly.

Old TODOs: (copied from earlier dec 12 - dec 19) (These have been rewritten in Jan23 notes in better format)

  • TODO: Make sure tests are working, and likely write some new tests
    • old/ServerOrig/ contains deliver-test-hacks.php which I probably need to use in the current server so that I can run my tests correctly. I'm not real clear on this.
  • TODO: Add a configuration to disable the liaison dashboard view.
  • TODO: Add configuration of disabled pages and (myabe) base_url to user configurations view on dashboard
  • TODO: User form submissions do not redirect back to the user dashboard ... fix that. (but how do I also display a success/fail message when doing that?) This is true on the dashboard for user login configuration. This is true on the reset password page. (ig that probably shouldn't redirect anyway... idk.)
  • TODO: Make sure admin configurations is covering everything (disabled pages!!!!)

/user/initialize/ doesn't work (DONE/SOLVED)

  • Package::__construct() calls get_user(). get_user() calls Lib::user_from_cookie(), which fetches from the database. This throws Uncaught PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'temp_user.user' doesn't exist
  • Possible solutions:
    • Pre-emptively create the tables
      • NO: The whole point of the /user/initialize/ feature is to make setup super easy and not command-line driven or code-driven.
    • Catch the exception ONLY if the initialization addon is active AND the url is correct
      • NO: This will probably be my solution. An issue with this is some slight extra overhead in running of the program.
      • I decided on DASHBOARD_WILL_DISPLAY hook + getting $user from lib directly on POST routes.
    • Catch the exception & allow the library to work without the necessary tables present (by using anonymous in-memory users only)
      • My gut tells me no. The whole point of the library is to provide a user login system. I can imagine somebody using it for throttling or something and NOT caring about the whole user-login thing, or wanting an extremely custom setup. But, I want to serve the library's core function extremely well, NOT cater to imagined edge cases. This does place some limit on the library, and I think that is okay (perhaps even ... good)
    • get_user() at a different point
      • NO: The Package class sets everything up, which includes adding the public_file_param $user, so that public files within this lib can access $user directly. (Note: afaik, public files in other packages will have to call upon the Package::get_user()). While it is possible to re-work this, I think it will be a mess. ... Actually, it is tempting to do this during the DASHBOARD_WILL_DISPLAY hook, BECAUSE as it stands, the get_user() overhead will happen on EVERY request, ALL OF THE TIME. That's a database call that may not be required on non-user pages.
      • ... Okay okay, POST pages do NOT involve the DASHBOARD_WILL_DISPLAY hook, SO ... I either have to figure out another hook-solution or call on lib directly in POST routes, or use the exception catching solution.

Dec 19, 2024

  • DONE I need two different test servers. Maybe three? Currently I have one that is both doing the initializtion testing AND the regular testing. The initialization testing has specific requirements that do not apply to a regular user lib install (pin file must exist. database will be created with a new admin user) so these two sets of tests should be separated.
  • DONE ensure that the admin dashboard addon ONLY does something if the logged in user is an admin
    • DONE see AdminDashboardAddon.php. I'm adding routes and views if the url is an admin route OR if the route is to the user dashboard. these checks should be improved. More rigid toward admin-only. i.e. check the view name when its a request for the dashboard.
      • using hooks in the AdminDashboardAddon for REQUEST_STARTED and DASHBOARD_WILL_DISPLAY
    • DONE Also ... idk when i'm adding the dashboard items ... but they're being added somewhere else.
      • Was adding them in package. Moved this to the AdminDashboardAddon
  • DONE The admin dashboard includes a view to see liaison install information. I want to re-enable that. currently it has an "I DONT KNOW IF I SHOULD HAVE THIS" text displaying instead of the actual lia info
  • TODO: Check tests, possibly write some new tests
  • TODO: Add a configuration to disable the liaison dashboard view.
  • TODO: Add configuration of disabled pages and (myabe) base_url to user configurations view on dashboard
  • TODO: Review Dec 12, 2024 TODOs

Dec 17, 2024

  • DONE visiting /user/dashboard/ displays message: Cannot display view, because it is not added to the dashboard.
  • DONE Update the language on the form for configuring the user login library
  • DONE allow configuration of the mail server settings via the dashboard form
  • DONE done-ish ensure that the admin dashboard addon ONLY does something if the logged in user is an admin
    • DONE TODO: see AdminDashboardAddon.php. I'm adding routes and views if the url is an admin route OR if the route is to the user dashboard. these checks should be improved. More rigid toward admin-only. i.e. check the view name when its a request for the dashboard.
    • DONE TODO: Also ... idk when i'm adding the dashboard items ... but they're being added somewhere else.
  • TODO: All the other things from Dec 12

TODO:

  • User form submissions do not redirect back to the user dashboard ... fix that. (but how do I also display a success/fail message when doing that?) This is true on the dashboard for user login configuration. This is true on the reset password page. (ig that probably shouldn't redirect anyway... idk.)

Dec 12, 2024

There is now a risky web initialization addon AND an admin dashboards addon. The admin dashboard panels are working! (actually there's just one). I've updated a bunch of viewnames to be namespaced user:ViewName instead of user/ViewName. I've updated a bunch of code to no longer reference EasyServer.

I want to:

  • DONE Update the language on the form for configuring the user login library
  • DONE allow configuration of the mail server settings via the dashboard form
  • DONE ensure that the admin dashboard addon ONLY does something if the logged in user is an admin
  • DONE in the dashboard_will_display hook ... i think this code is all in package. adding the admin dashboards should be done in the admin dashboard addon. Just need to move that code over, I think.
  • DONE The admin dashboard includes a view to see liaison install information. I want to re-enable that. currently it has an "I DONT KNOW IF I SHOULD HAVE THIS" text displaying instead of the actual lia info
  • DONE I need two different test servers. Maybe three? Currently I have one that is both doing the initializtion testing AND the regular testing. The initialization testing has specific requirements that do not apply to a regular user lib install (pin file must exist. database will be created with a new admin user) so these two sets of tests should be separated.
  • old/ServerOrig/ contains deliver-test-hacks.php which I probably need to use in the current server so that I can run my tests correctly. I'm not real clear on this.
  • Overall, I need to make sure tests are working
  • Make sure admin configurations is covering everything (disabled pages!!!!)

Dec 11, 2024 (ending Dec 12 but barely)

I moved test/Server/ to test/ServerOrig/ and moved the ServerIWant to just Server (because phptester wasn't working with my configured servers).

I made the Package class work with the Initialization addon, and I made some small code updates to fix some errors. I made the initialization addon setup its public routes & views.

I have not yet removed EasyServer. Also, I made a whole fuss about setting up a package config file, but the initialization addon isn't currently doing anything with a config file. no configs are being stored. This might be happening on the dashboard, though.

Additionally, I'm throwing an error when the initialization pin file doesn't exist ... but I had this idea that these user package configurations would only be configurable when the initialization addon was active. So I'll have to figure that out.

I could maybe have two addons, with their own sets of public routes & views?

  • One for the initialization (create database tables and create initial admin user)
  • Another for admin-level configurations. This way, the developer has the choice to disable admin-configurations alltogether (then they'd have to manually edit the json file to setup mail configurations & stuff).

That would probably be fine. It would separate the "risky web initialization" which REALLY IS RISKY, from the standard admin-level things. Giving web access to recreate your database and add an admin user is kinda wild and a bad idea. But having configurable mail server settings seems a lot more reasonable and useful.

Run gp easy_user_server on the repo to see where the EasyServer class is being used. It's not a lot of places. I think I basically just need to move functionality from the easy server class into the package class.

That, and I do want to separate the risky init stuff from the regular admin mailserver config stuff.

Dec 9, 2024

I created test/ServerIWant/deliver.php with some sample code and notes.

The note from Sep 10th: I was getting way too ahead of myself. I should work with the current Liaison architecture and get things working. I'm fine getting rid of the EasyServer class & instead doing this easy-initialization stuff as part of an additional addon (except src/init/* looks more like a package than an addon.) If I still want to improve liaison afterward, that's fine. But I should have the user lib working with the current liaison. Doin the liaison changes first just cascades too many issues to tie these two changes together without first completing the updates to the user lib.

Sep 10, 2024

Major code reorganization, in progress to remove the EasyServer class and replace it with just using the User Package & calling a method to enable the initialization pages, via a new addon just for that purpose.

The User package WAS working as-is, but I moved the views from view/user/* to view/* because Liaison respects view namespaces now (it might have before, too idr). My view calling code does NOT reference namespaces, so many tests are now failing.

The Easy Server stuff is not implemented. I created src/init/ dir, which contains the initialization public files, views, and an addon class. That code will be part of the user package, but will have to be added manually by calling $user_package->enable_risky_initialization_pages() (or something like it). The Addon will then handle adding it's public dir & views, and will have to ensure consistent url prefix & namespacing when doing so.

I'm finding myself quite frustrated with Liaison. It's addon method signatures are naked with no params or types or return type (void).

I think I'm going to go to Liaison & udpate these method signatures & all the built-in addons. I think I'm going to convert the init_lia() method into an onLiaReady() method to ... to make it less stupid & more consistent with onPackageReady().

So I should probably do that liaison stuff before writing the user initialization addon, if I decide to go that route.

I need to remember to avoid MAJOR refactors and rewrites. I think this method-signature one is pretty minor, should take less than 2 hours (probably less than 1), and is super important because it really just adds the paramater list & return type of void.

Sep 9, 2024 (same session, little later on)

I did not use the SplObjectStorage approach, because wasn't working as expected. I now have a static array of cookie codes that are invalidated, then a cached user can only be returned if the cookie is not listed in the invalidated cookies array.

This means there is some tiny risk that a user who SHOULD be in cache gets removed from cache & this could cause additional database queries.

The risk is extremely extremely low, though, due to cyrptographically secure random cookie keys. And if this happens, it's a minor performance hit, not a security threat, because it means a DB query is required to get a valid user.

At no point is a cached user being returned that has been invalidated.

Sep 9, 2024

I already fixed most the tests, see git log.

Notes on user cache and invalidating the cache of logged-in-users Previously, there was no cache of users in-memory I added a cache for users loaded from cookie, to prevent extra database trips Users are logged OUT through the User class, which does NOT have access to a Lib instance. So I must decide:

  1. When $user->logout() is invoked, should that user be removed from the cache?
  2. If no, how do I document/communicate this behavior? It's not intuitive.
  3. If yes, how do I implement it?

Answers:

  1. yes. There's an arguable case for leaving user in-cache for the remainder of the request BUT I think the argument for clearing the cache is better Mainly in that leaving user in-cache will create unexpected outcomes that could potentially lead to security issues. I've considered the counter argument: If a user was authenticated at the beginning of a request, then the request is authenticated for such-and-such actions, and it would be quite peculiar to log a user out THEN check for certain authorization But "quite peculiar" is a bad argument. This is programming and we gotta do weird shit all the time.
  2. not applicable
  3. I'm considering: a. Convert Lib->cookie_users from instance array to a static SplObjectStorage. The User Class can then pass its PDO instance and cookie string to the Lib instance to remove a cached user, using PDO instances as keys pointing to a group of cached users-by-cookie.

Sep 6, 2024

  • Reverted v0.3 to its last working state

I'm so frustrated and confused. I'm not getting any error messages on the PostNewPassword test. It's not calling the send_email() method on lib. But I swear it was like 15 minutes ago and I don't see any code change in my diffs. So I'm just reverting changes and walking away. I don't know what's happening. I don't know how to fix it. I have no patience and I'm having a terrible time.

Next time: Make sure you're in a good mood before you start & that your body feels good. Make sure you're cool (temperature wise) and feeling patient. Whatever the problems here are ... they're confusing, they're difficult, they're complex.

There's additional problems. Like, some of the documentation is a bit meh. The fact that I'm using this EasyServer class is confusing. I want it all in package. The separate Lib class sometimes is idk ... It just feels like there's 3 or 4 different main classes & there needs to be only one.

But my desire to refactor that might be a bit of over-engineering. Maybe I just need to fix things with the current architecture.

Sep 2, 2024 later

TODO: I should probably revert v0.3 back to its last working state.

I need to get all the tests passing again.

I started in CompletePasswordChange.php in the test testPostNewPassword.

SendEmail is mad that certain configs are not set. I could use the mail service debug switch to add debug values for those.

I'm too tired i don't want to explain more, fresh me will figure it out just fine.

Sep 2, 2024 BUMPED

Bumped to v0.4! Updated liaison dependency. But there's another dependency (taeluf/server v0.2) which requires liaison v0.6 and I can't composer update.

Sep 2, 2024

I am bumping this to v0.4. I've been making lots of changes to it, and I want more leeway to make big changes and not worry about breaking old setups.

v0.4 will depend upon Liaison v0.7 (which is also a bump from v0.6 for the same reason)

Sep 1, 2024

I added a new package class for the user lib & implemented it in the EasyServer class. It is very barebones. I did not update any documentation or do any meaningful refactor

Aug 20, 2024

I forgot to take notes earlier, so see my git log:

  • a0f151a - (HEAD -> v0.3) add docs url to scrawl.json (6 seconds ago) <Reed Sutman>
  • 8ffd97e - (origin/v0.3) add DASHBOARD_WILL_DISPLAY hook to protect some panels from being accessible by non-admins. Add a Liaison Site Details panel to the dashboard that dumps lots of liaison information. Super useful, but I disabled it due to concerns of security risk that I need to think about before enabling in the git repo. (17 minutes ago) <Reed Sutman>
  • 7d2d861 - minor README fixes (7 hours ago) <Reed Sutman>
  • e2998fb - remove unnecessary section from readme (7 hours ago) <Reed Sutman>
  • 4f509b2 - major improvement to uconfiguration & mail settings documentation (7 hours ago) <Reed Sutman>
  • b2da5bd - user login configuration dashboard now submits successfully & actually updates user configs! (7 hours ago) <Reed Sutman>
  • f88b0ab - minor doc changes, run scrawl (8 hours ago) <Reed Sutman>
  • 064057e - configs work and documentation updates in progress (8 hours ago) <Reed Sutman>
  • 5d8d359 - progress toward consistent configurations (8 hours ago) <Reed Sutman>
  • 18ebc72 - slight form update (9 hours ago) <Reed Sutman>
  • 9919953 - update configure-login form. Add configurations class to define configurable keys (other code not yet updated to new keys) (9 hours ago) <Reed Sutman>

Aug 19, 2024 (later)

I started a configure-login dashboard, but I didn't put proper checks on when adding the dashboard panel. I want to be able to code which users are able to access admin dashboards. This could be a callable that takes a user & returns true if they can access admin dashboard, otherwise false. And/Or there could be preset options, like users with a programmatically defined role or programmatically defined permission (or just a specific user email). You'd select the type from an enum and then provide a value like role admin or permission admin.view_dashboard or email reed@example.com.

I left configure-login in an incomplete state & I did not implement the POST side. See:

  • view/user/admin-dashboard/configure-login.php
  • public/admin/@POST.configure-login.php
  • EasyServer.php -- Ensure admin dashboard access is allowed before adding the panel to the dashboard. Consider setting up another hook, for dashboard_will_display, at which point I can add panels that are more intensive to add (i.e. a user's role check is needed. Let's not do this every request)

I did not complete the TODOs from aug 19

Aug 19, 2024

TODO: I'm setting up the PHPMailer implementation, and in it I set the from and the reply-to programmatically. Well, the Validation/SendEmail.php script already passes from and reply-to in the additional mail headers. The settings I'm using in that class are named differently than the user configs I now want to use in the MailService function that uses phpmailer. I need to ensure consistency among these configurations & also not double-up work.

TODO: I need a programmable setting that controls which users have access to admin dashboard features. I want it to be users with the 'admin' role, but this should be configurable, at least programattically (probably preferable that it's programattic, because it reduces risk of a bug allowing a change to this setting in production, which then could allow any user to use the admin dashboard).

TODO: $lib->config Expects web_address = http://example.com and email_from = help@example.com. Idk I'm just not happy with this. I think I need different prefixes & to setup defaults or maybe throw an exception. In EasyServer I'm explicitly setting $lib->config['web_address'] = $configs['user.web_address']; and $lib->config['web_address'] = $configs['user.email_from']; and I don't like this.

TODO: For mail & user configurations not set, we should throw an exception rather than have fail silent defaults like example.com or noreply@example.com. See configs in EasyServer.

DONE: I have a fully functioning PHPMailer implementation, as well as three other send mail options (callable, php mail, and debug to text file

Aug 18, 2024 (~3pm - 5pm)

Did:

  • added styling to dashbaord
  • retired profile page (placeholder page exists, directing you to dashboard)
  • Added some light form styling
  • Recreate help page & made help/security-logging page
  • Updated the 'agree to security logging' to be a message and implicit agreement rather than a checkbox

Notes:

  • there's no security log for user logouts
  • I don't seem to have any way to disable pages in the new setup

Next time:

  • Add admin-only dashboards items:
    • view users
    • manage roles & permissions
    • Configure contact url & email address

Aug 18, 2024 (at 12:58 in the morning)

Setup a dashboard page with 3 available dashboards:

  • Main: Link to set new password & link to terms
  • Your Permissions: roles & permissions list
  • Security Logs
  • Logout

The /profile/ url is still being used. (the dashboards were copy+pasted from there). /profile/ needs to be retired.

It is organized like this:

  • Request hits public/dashboard.php & checks if user is logged in
  • If yes, load view user/dashboard.php
  • There, load a view that's been added via $lia->addUserDashboard(name, viewname), and print it;

Three view files were created:

  • code/view/user/dashboard/main.php
  • .../dashboard/permissions.php
  • .../dashboard/security_logs.php

Next up is retiring the profile url and improving the dashboards, and possibly adding more dashboards.

Aug 16, 2024 (but writing these notes after midnight, so august 17th technically)

I think I finished the security apparatus of the initialization page. I also added database initialization.

The initialization script requires the pin file to exist, to contain a pin from 20-40 characteres, and have no users exist in the database. If a PDO exception is thrown, the script fails, unless the error message contains SQLSTATE[42S02] for the table not existing.

For changes to be saved, the stored pin must be POSTed through the form, and the initialization pin file must be successfully deleted.

The script definitely needs to be double-checked for errors, and maybe triple-checked.

I'm not actually sure how to use the logged in user on the site. I need to document that. I think I implemented it last time.

I also just need to document the entire new setup process.

Aug 15, 2024

Building initialization feature & easy server setup to have a fully functional user login gui with very little setup. I stopped midwork because it's late. I was working in the initialize page to handle database initialization, but I got an error about the tables not existing. So I separated user login into get_user() in EasyServer, which will probably work, but then I just got stuck thinking about if I need to modify the deliver script & if I need to control for the specific page url ... i just got stuck mentally so I'm stopping.

Files made:

  • public/@POST.@GET.initialize.php
  • code/class/EasyServer.php
  • test/EasySetup/*

Dec 8, 2022

  • Upgrading to work with php8.2
  • Working on tests (DONE)ThrottleLoginUser and (DONE)Server,
  • the cookie expires string from setcookie() uses the format D, d-M-Y H:i:s e in php8.1, but uses D, d M Y H:i:s e in php 8.2

May 4, 2022

  • special, brief T&Cs for login & password reset

Things

  • re-build sql
  • bin/tlfuser build to serialize the sql files
  • bin/tlfuser init to create the user database, loading db settings from .config/env.json

Tests TODO

  • test that $user->all_roles returns a role even if there are no associated permissions

Versions

  • v0.1: old version, old Liaison
  • v0.2: New version, liaison v0.5
  • v0.3: Removing Sentinel dependency

TODO MVP

  • add roles with no permissions to list of roles on user profile page

  • delete all the old code

  • MAYBE easy way to delete expired throttles & expired codes (for cron jobs)

  • add cookie info to the terms & conditions

  • add a help page

  • make compatible with liaison v0.6??

  • add easy liaison/server integration

  • DONE $lib->role_deny('role', 'permission') and $lib->role_delete('role'), then add it to the docs test & main tests

  • DONE basic README

  • DONE t&c + privacy policy

  • DONE disable pages

  • DONE csrf tokens: See https://www.taeluf.com/blog/php/security/csrf-validation/ for my notes

    • DONE request password
    • DONE complete password
    • DONE register
    • DONE login (validation engine + csrf)

  • DONE UPDATE enable_csrf() to actually generate a random code

  • DONE disable forced csrf approval when user agent is present (so i can properly test csrf in the browser) & properly test csrf in the browser

  • DONE simple 'profile' page

    • DONE email
    • DONE permissions, roles
    • DONE change password button (takes you to reset password page)
    • DONE security history (logins, password resets, registration, ...)
    • DONE link to terms & conditions

  • DONE /user/ should redirect to profile page or login page

  • DONE log actions:

    • DONE emails being sent (probably?)
    • DONE terms & conditions agreement
    • DONE login
    • DONE register (this presumes full T&C have been agreed to)
    • DONE complete registration (landing on the page)
    • DONE request password reset
    • DONE complete password reset (this presumes registration has been completed & full t&c were agreed to)
      • DONE submitting the form
      • NO landing on the page? probably ... no, not for landing on the page, only for submitting the form

  • DONE basic spam control:

    • DONE honey pot
    • DONE generate code & auto-fill with js (plus <noscript> for folks who need it)

  • DONE Polishy things

    • DONE /user/login/ should show logout link if currently logged in
    • DONE logout page should have link to login
    • DONE show password requirements on register & set new password page
    • DONE terms & conditions checkbox on register page
    • DONE check if user is currently logged in & redirect or provide link and/or message as needed
      • DONE registration page
      • DONE login page
    • DONE log better messages like "login failed" or "registration failed" ... Maybe "login attempt" followed by "successful login"?? Or just write a message on the profile page that tells you the logging is bad lol
    • NO in email sent to complete registration & to complete password reset, include message about security logging (or don't because that's part of the greater T&Cs when you register & you only get a link if your account is active) ... not changing the email content bc the security logging is covered by the terms & conditions when registering

TODO eventually

  • DONE convert login to validation engine
  • Testing
    • when mail() returns false (this theoretically shouldn't happen, but still...)
    • /user/ redirects properly
    • /user/profile/ displays 'not logged in' message + links
    • /user/profile/ displays permissions & security & stuff
    • logging in general
  • GUI stuff
    • edit user form (change email? shoot ... that might be a future feature)
    • admin/user-management (may be able to defer this & rely on backend setup code)
      • enable/disable registration
      • create user
      • delete user
      • create/delete role
      • add role to user
      • add permission to role
      • add permission to user
      • remove role from user
      • remove permission from user

Niceties that I'm putting off

  • an sql file that holds all the sql queries, generated by LilSql
  • A 'messages' file that holds all the messages we send to users. Then allow the messages to be modified by the programmer. Use sprintf(), probably to fill in certain details like email addresses & urls. Or maybe use a lazy binding method like preg matching :some_key type of thing
  • LATER pre-fetch permissions for a user. Probably LIMIT 100? Or MAYBE only load role-based permissions, as that will be a shorter and more frequently used list. I'm trying to minimize db round trips, especially in production where the database is over IP.
  • LATER add error reporting? (just simple callback function)
  • LATER validate the code type passed to new_code() (like using an enum ...)
  • LATER normalize the password hashing into a method
  • LATER rethink is_active for the code table ... it semantically is meh
    • password_reset: is active once the password is successfully reset
    • login_cookie: is active as soon as it's created
    • registration: is active once registration is completed
      • but "is active" should mean "is the code active", which means "can the code be used" ... which kinda means that registration & password_reset should start active & then be de-activated (as should login_cookie)
      • this isn't super important, as long as I document & test. It would be nice to have semantic intuitiveness though
  • LATER maybe register() should return a code for registration
  • LATER a simple/small framework for writing named sql queries in an sql file & loading them dynamically into php. Something like ;;;QUERY_NAME then the query starts on the next line. This would be some overhead, but would be nice for portability & would allow me to dynamically EXPLAIN any query. Alternatively, I could just wrap my pdo prepare() call in a method that can add EXPLAIN for debugging/optimizing